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history  of  Air  Force  systems  engineering  management.  It  summarizes  the  results 
of  the  study:  a  Requirements  Engineering  Guidebook,  an  example  using  the 
Guidebook,  associated  automated  tool  capabilities,  automated  tool  design 
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Guidebook.  The  Requirements  Engineering  Guidebook  describes  the  character¬ 
istics  of  good  requirements,  the  various  system  requirement  types,  and  the 
requirements  engineering  procedures.  The  requirements  engineering  procedures 
are  described  In  the  form  of  a  procedural  t low  with  accompanying  guidelines 
and  standards  for  performing  fourteen  requirements  engineering  activities. 

Each  requirements  engineering  activity  is  supplemented  by  a  description  of 
t he  spec i t Ic  issues  to  be  addressed  during  the  first  two  phases  of  the  Air 
Force  acquisition  life  cycle  -  the  Conceptual  and  Validation  Phases. 
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PREFACE 


This  report  is  one  of  three  volumes  prepared  to  assist  government  and 

contractor  personnel  in  managing  and  performing  system  requirements 
definition  and  analysis:  requirements  engineering.  The  primary  results  of 
this  study  has  been  the  definition  of  guidelines  and  standards  for 

requirements  engineering  (Requirements  Engineering  Guidebook)  and  the 
identification  of  automated  aids  to  support  the  application  of  the 
guidelines  and  standards  during  the  initial  phases  of  the  Air  Force  system 
acquisition  life  cycle  -  the  Conceptual  and  Validation  Phases. 

This  study  reflects  Logicon's  experience  with  an  automated  requirements 

engineering  tool  applied  in  support  of  the  acquistion  of  a  large  Air  Force 
surveillance  system.  The  Requirements  Engineering  Guidebook  reflects  the 
needs  of  an  Air  Force  System  Program  Office  acquisition  environment; 
however,  the  basic  requirements  engineering  principles  and  guidance  are 
easily  adapted  to  other  acquisition  environments. 

This  report  was  prepared  by  Logicon  for  the  Air  Force  Systems  Command 

(AFSC),  Rome  Air  Development  Center  (RADC),  Software  Engineering  Section. 
Administrative  review  and  technical  coordination  of  this  report  have  been 
accomplished  for  RADC  by  Mr.  Michael  Landes  (project  officer). 

Review  of  this  report  was  accompl ished  at  RADC,  by  Electronic  Systems 
Division  (AFSC/ESD)  personnel  at  Hanscom,  AFB,  and  by  Logicon  personnel. 
Special  thanks  to  the  many  reviewers  and  for  the  patience  and  skills  of  Ms. 
Marcia  Brehm  and  Ms.  Deborah  Queen  for  the  technical  typing,  proofing,  and 
revisions. 


TABU  Of  CON  TINTS 


i'jjje 


1.  INTRODUCTION  .  1 

0.  AIK  I  OK  CL  SYS  U  MS  uNu  INURING  MANAGLMLNT . 0 

3.  STUDY  APPROACH . 4 


4.  RtQUIKtMINTS  LNOINlLKINU  SIANDAKO 


7 


Requirements  engineering  .  7 

Quality  Requirements  Characteristics  .  8 

System  Requirement  Types  .  lb 

Requirements  engineering  Procedure  .  18 


Ktgu IRt Mt  NTS  LNG.NLCRINC,  TOOL  CAt'ABILlTlLS 


.’1 


Intrinsic  Capabilities  ot  Automated  Tools 
Language  Objects  and  Relationships  .  .  . 

The  Analyzer  . 

Requirements  Data  Base  Management  .  . 

functional  Analysis  . 

I/O  Analysis . 

T  rac eab i 1 1 ty  Ana  lysis . 

Test  Analysis  . 

Documentation  . 


01 

00 

07 

27 

08 

08 

29 

29 

0° 


b.  ADDITIONAL  STUDY  K l BOLTS 


30 


Requirements  engineering  example  .  30 

Implementation  Approach . 30 

Automated  Tool  Design  Approaches  .  32 

RLSULTS  AND  KeCOMMt  NDAT10NS . 33 


The  Requirements  engineering  Guidebook 

CADSA T  I  nhancement s . 

extended  CADSAT  Capabilities  . 

Lvolut lonary  Approach . 

Requirements  engineering  Methodology  . 


33 

34 
34 


3o 


37 


RLf  1  Kl  NCI  B 


LIST  OF  FIGURLS 


Page 

1.  Requirements  Standards  Study  Technical  Approach . 5 

2.  Development  of  Discrete  and  Wei  1 -Organized  Requirements . 9 

J.  Space  System  X:  Functional  Hierarchical  Structure  .  12 

4.  Space  System  X:  Control -Flow  Diagram . 14 

5.  Space  System  X:  Requirements  Traceability  Report . IS 

6.  Requirements  Engineering  Procedures . 19 


7.  Functional  Hierarchical  Structure 


8.  I/O  Hierarchical  Structure  .  24 

9.  Control -Flow  Diagram  .  26 

10.  Information  -Flow  Diagram . 26 


LIST  OF  TABLES 


1  System  Requirement  Types  .  17 


v 


evaluation 


This  report  contains  a 
standards  pertinent  to 
system  development.  I 
an  t  o m a  t  e d  tools  t' o r  I m 
This  report  is  on e  o t 
in  format  ion  and  guidan 
s  v  s  t  em /  s egme n  t  s p  e  e  i  f  l 
r  e  q  u  I  r  e  m  e  n  t  s  (MI  I.-STP- 
technical  o  v  e  r  v  i  e w  d  e  s 
technical  approach,  an 
eng  ine e  r  i  n  g  m a  n a  g e m  cut 
study:  a  Requirements 
using  the  Guidebook,  a 
tool  design  approaches 
the  Guidebook  in  t  lie  A 
cycle.  Volume  11  ex  p a 
the  first  volume.  Vol 
En  >'  ineer  i  n  .  Gil  i  d  e  bo  o  k  . 
istic s  of  good  require 
types,  and  the  require 


comprehensive  survey  of  existing 
the  requirements  phase  of  software 
t  also  contain .  material  bearing  on 
proving  management  of  this  phase, 
three  volumes  which  provide 
ce  for  defining  and  analyzing  military 
cation  and  development  specification 
490/483  ( U S A F ) )  .  Volume  1  is  a 
eribing  the  purpose  of  the  study,  t  lie 
d  a  history  of  Air  Force  systems 
.  it  summarizes  the  results  of  the 
E ng ineer ing  Guidebook,  an  e x a m pie 
ssociated  tool  capabilities,  automated 
,  and  recommend at  ions  on  implementing 
i r  F o r  c e  s  y  s t e m s  a cqu is  it  i o n  1 i f e 
mis  upon  the  material  summarized  in 
time  Ill  is  the  Requirements 

Volume  III  describes  the  c ha rac ter¬ 
ra  ents,  the  various  system  requirement 
ment s  e n  g ineer  i  n  g  p  r o c e dnrcs. 


tills  comprehensive  study  comprise  the 
Air  Force  Guidebook  for  use  on  software 
i  s  1 1  i  o  n  which  is  of  value  for  immediate  use 
for  guiding  research  and  development  efforts  toward 
generating  automated  tools  in  the  requirements  phase  of 
so !  t  wa  r e  d ev  e 1 o  pm en  t . 


T  h  e  c  iint  e  n  t  s  o  f 
main  body  of  i n 
sy  a  t em  ac  qn 


a  n  d 


>  > 


/MICHAEL  LANDES 
Project  Engineer 


vi 


1. 


INTRODUCTION 
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Military  systems  acquisition  has  a  highly  regulated  environment.  However, 
many  of  the  military  system  engineering  management  procedures  are  not 
appropriate  for  the  complexity  of  the  systems  being  procured.  This  volume 
surmiari^es  the  results  of  a  Logicon  study*  for  the  Air  Force  in  which 
guidelines  and  standards  for  systems  requirements  definition  and  analysis 
have  been  developed  for  the  initial  phases  of  an  Air  Force  systems 
acquisition.  The  guidelines  and  standards  are  presented  in  the 
Requirements /'Engineering  Guidebook,  the  third  volume  of  this  three  volume 
report.  Gi/dance  is  provided  for  defining  and  analyzing  the  requirements 
for  the  system  as  a  whole  (Conceptual  Phase).  Additional  guidance  is 
provided  for  expanding  and  refining  the  initial  definition  by  the 
allocation  of  the  requirements  to  specific  components  of  the  delivered 
system,  with  specific  emphasis  on  computer  program  development 
Specifications  (Validation  Phase). 

if 

This  volume  presents  an  overview  of  the  Air  Force  systems  acquisition 
environment  and  associated  requirements  engineering  problems.  This  volume 
briefly  discusses  the  methodology  applied  during  the  study  and  the 
technical  results. The  technical  results  concentrate  on  the  Requirements 
Engineering  Guidebook,  including  a  description  of  the  characteristics  of 
quality  rtqui rements^ ,  a  discussion  of  various  requirements  types,  and 
the  procedures  for  Conceptual  Phase  and  Validation  Phase  requirements 
engineering.  The  Requirements  Engineering  Guidebook  is  described  and 


*  This  work  is  supported  by  F30602-77-C-0207. 
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The  term  quality  requirements1  is  used  throughout  this  study  to 
denote  system  requirements  which  are  complete,  consistent,  testable, 
and  traceable.  This  characteristic  is  the  result  of  the  requirements 
being  discretely  identified  and  well-organized  as  discussed  in  the 
sections  to  follow. 
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supported  by  sample  output  from  a  comprehensive  automated  requirements 
engineering  tool  which  is  currently  being  employed  by  Logicon  on  an  Air 
Force  project.  This  volume  discusses  the  development  of  a  list  of 
automated-tool  capabilities  which  support  the\  Requirements  Engineering 
Guidebook,  concluding  with  a  list  of  recommendations  for  further  research 
activities. 


2.  AIR  FORCE  SYSTEMS  ENGINEERING  MANAGEMENT 

The  complexity  of  military  systems  development,  has  continued  to  outpace 
the  management  and  technical  resources  supporting  the  acquisition  process. 
Our’ng  the  19b0s  and  into  the  early  1970s,  systems  development  in  the  Air 
Force  Systems  Command  (AFSC)  was  regulated  by  a  series  of  manuals,  the 
AFSCM  375  series.  Two  of  these  manuals  concentrated  on  system  engineering 
procedures  (AFSCM  375-5  [1])  and  documentation  (AFSCM  375-1  [2]).  This 
highly  regulated  approach  was  necessitated  by  the  increasing  delivery  of 
obsolete  systems,  which  resulted  from  the  less  regulated  systems 
development  approaches  of  previous  decades  ( 1 940s- 1 950s ) .  Added  to  this 
obsolescence  problem  was  the  rising  complexity  of  the  systems  being 
developed  to  meet  the  national  defense  needs  of  the  post  World  War  II 
decades,  including  the  increased  application  of  systems  with  embedded 
software.  ' 

The  AFSCM  375  series  provided  for  flexibility  in  its  application  but  was 
not  completely  understood.  As  a  result  of  the  difficulties  encountered  in 
applying  AFSCM  375,  the  Air  Force  began  to  rescind  parts  of  the  series 
during  the  late  1960s.  The  Air  Force  documentation  requirements  of  AFSCM 
375-1  evolved  almost  unchanged  into  the  present  standards  for 
specification  practices,  M1L-STD-490  [3]  and  MIl-STD-483  (USAF)  [4].  The 
system  engineering  procedures,  AFSCM  375-5  evolved  into  the  present 
regulation  for  Air  Force  program  office  engineering  (AFR  800-3  [5]). 
Contractor  system  engineering  requirements  are  described  in  the  present 
Air  Force  standard  for  engineering  management,  MIL-STD-499A  (USAF)  [6]. 

\ 
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As  previously  reported  [7],  it  is  becoming  evident  that  present  military 
manayement  practices  and  technical  resources  are  not  adequate  for  the 
increasinyly  complex  military  systems  beiny  developed.  A  principle  area 
of  deficiency  has  resulted  from  the  inadequacies  of  the  system  enyineering 
guidelines  in  MIL-STD-499A  and  AFR  800-3.  In  the  wake  of  rescinding  the 
system  engineering  requirements  of  AFSCM  3/5-5,  significant  practices  for 
systems  requirements  engineering  were  not  translated  or  updated  into 
present  practices.  As  a  result  many  essential  requirements  engineering 
practices  are  non-existent  or  have  been  de-emphasi zed. 

m 

This  trend  toward  less  regulated  Air  Force  systems  engineering  manayement 
has  been  encouraged  by  defense  contractors  in  a  desire  to  allow  for  more 
competitive  and  innovative  approaches  to  systems  development.  Numerous 
contractors  have  responded  by  developing  systems  engineering  procedures. 
However,  other  defense  contractors  and  military  agencies  have  not 
developed  systems  engineering  or  management  practices  which  satisfy  the 
real  technical  and  management  needs  of  Air  Force  programs. 

In  recent  years  systems  requirements  engineering  has  received  renewed 
attention  within  academic  and  military  research  and  development  (R&D) 
environments  and  is  now  coming  to  the  forefront  of  research  and 
applications  for  improved  military  systems  development.  AFSC's  Llectronic 
Systems  Division  (LSD)  has  acquired  a  computer-aided  requirements 
engineering  tool,  CADSAT,  and  has  encouraged  the  application  of  this 
computer  aid  in  Air  Force  requirements  engineering  activities.  1  Logicon 


The  Computer-Aided  Design  and  Specification  Analysis  Tool  (CADSAT)  is 
an  A i r-F orce-owned  requirements  analysis  tool  developed  by  the 
University  of  Michigan  under  ESD/TOI  contract  F 1 9628- 76-C-0 1 9 7 .  [8]  [9] 
The  extended  version  is  a  modification  developed  by  Logicon  for  applica¬ 
tions  to  military  systems  under  ESD/OCU  contract  F19628-76-C-0218. 
CADSAT's  User  Requirements  Language/User  Requirements  Analyzer  (URL/URA) 
is  basically  equivalent  to  the  Problem  Statement  Language  and  Problem 
Statement  Analyzer  (PSL/PSA)  developed  at  the  University  of  Michigan. 
[10] 
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systems  analysts  have  employed  CADSAT  tor  several  .ears  in  defining  and 
analyzing  the  system  requirements  for  a  large  Air  Force  surveillance 
system.  As  a  result  of  this  application,  Logicon  has  made  extensions  to 
CADSAT  to  satisfy  requirements  engineering  management  and  technical  needs. 
These  extensions  have  made  CADSAT  more  suitable  to  specific  military 
systems  acquisition  activities.  As  with  other  research  directed  in  recent 
years  toward  defining  standards  for  modern  program  ing  practices  in  Air 
Force  systems  development,  requirements  engineering  is  being  identified  as 
a  target  for  improved  standardization.  Within  this  renewed  interest  and 
based  upon  the  surveillance  system  experience  using  CADSAT,  Logicon  began 
developing  a  requirements  engineering  standard  in  1977  under  contract  to 
the  Rome  Air  Development  Center  (RADC),  Griff iss  AFE,  New  York.  This 
study,  titled  the  Requirements  Standard  Study  (RSS),  is  based  upon 
Logicon's  requirements  engineering  experience  and  the  use  of  CADSAT.  The 
primary  results  of  the  RSS  are  a  Requirements  Engineering  Guidebook  (Volume 
III)  and  the  identification  of  automated  aids  to  support  the  application  of 
the  Guidebook.  The  Guidebook  has  been  developed  in  response  to  the 
requirements  engineering  inadequacies  of  the  current  Air  Force  system 
engineering  procedures.  However,  the  principles  of  the  Guidebook  are 
applicable  to  other  systems  acquisition  environments. 

3.  STUDY  APPROACH 

The  RSS  was  organized  into  the  series  of  tasks  shown  in  Figure  1.  An 
extensive  literature  search  identified  existing  military  regulations, 
standards,  and  specifications  and  a  variety  of  guidebooks  and  handbooks. 
Past  and  present  DoD  research  projects  were  reviewed  through  the 
interactive  query  facility  of  the  Defense  Documentation  Center.  In 
addition,  professional  journals  and  conference  proceed i ngs  were 
researched.  As  pertinent  documentation  was  identified,  bibliographic 
information  on  each  was  entered  into  a  computer  maintained  file.  The 
complete  bibliography  is  included  in  Volume  I!  of  this  report. 
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The  principle  tasks  of  the  study  concentrated  on  developing  guidelines  and 
standards  for  requirements  engineering.  The  Requirements  Engineering 
Guidebook  was  a  product  of  the  first  three  RSS  tasks.  The  Guidebook 
concentrates  upon  the  first  two  Air  Force  system  acquisition  phases,  the 
Conceptual  and  Validation  Phases.  The  Conceptual  Phase  is  the  initial 
period  when  the  requirements  are  defined  for  the  system  as  a  whole.  The 
Validation  Phase  expands  and  refines  the  Conceptual  Phase  requirements. 
During  the  Validation  Phase  the  requirements  are  allocated  to  specific 
end-items  which  are  configured  into  the  delivered  system,  such  as  hardware 
(radars,  computer  equipment,  etc.),  and  other  items  such  as  computer 
programs.  The  RSS  concentrated  on  the  development  of  computer  program 
requirements. 

As  the  preparation  of  the  Guidebook  continued,  the  role  of  automated 
assistance  to  support,  the  Guidebook  was  addressed.  In  developing  the 
Guidebook  the  necessary  requirements  engineering  activities  were  viewed 
from  a  systems  engineering  perspective.  Existing  automated  tools  which 
have  evolved  from  academic  and  R&D  environments  lack  many  of  the 
fundamentals  of  requirements  engineering  needs  of  the  Air  Force  systems 
engineering  process.  The  RSS  review  suggests  that  these  initial  tools 
were  designed  with  a  bias  toward  later  phases  of  systems  development  and 
are  burdened  by  the  same  problem  experienced  with  most  other  software 
systems:  existing  automated  requi rements  definition  and  analysis  tools 
are  attempting  to  solve  an  undefined  problem  ( i . e . ,  the  requirements  for 
the  tools  are  ill-defined).  The  requirements  engineering  process  must  be 
defined  within  fhe  systems  engineering  process  with  specific  attention  to 
the  early  phases  of  system  requirements  engineering,  then  the  study  of 
automated  assistance  in  accomplishing  the  requirements  engineering  tasks 
may  proceed.  The  latter  was  the  objective  of  the  RSS.  As  a  result,  the 
requirements  engineering  tool  capabilities  which  support  the  Guidebook 
were  separately  identified  and  described.  Next  a  description  of  two 
approaches  for  automated  assistance  in  support  of  the  Requirements 
Engineering  Guidebook  was  addressed. 


This  final  technical  report  contains  the  following:  the  Requirements 
Engineering  Guidebook,  a  description  of  automated  tool  capabilities  which 
can  support  the  Guidebook;  examples  of  the  use  of  an  existing  automated 
tool  (Logicon-Extended  CADSAT)  using  the  Guidebook,  a  description  of  two 
approaches  for  applying  CADSAT  in  support  of  the  Guidebook,  recommendations 
on  implementing  the  Guidebook  within  the  existing  regulations,  applicable 
standards  and  specifications,  and  other  results  and  recommendations. 

4.  REQUIREMENTS  ENGINEERING  GUIDEBOOK 


Requirements  Engineering 

During  this  study,  requirements  engineering  was  determined  to  be  a  distinct 
engineering  discipline  which  needs  to  be  addressed  separately  from  other 
aspects  of  systems  engineering.  During  the  l%0s  requirements  engineering 
was  integral  to  the  procedural  aspects  of  the  system  engineering  process 
established  under  AFSCM  375-5.  Neither  the  current  military  standard  for 
engineering  management  (MIL-STD-499A)  nor  the  guidance  for  program  office 
engineering  (AFR  800-3)  define  requirements  engineering.  Requirements 
engineering  is  vaguely  defined  to  be  part  of  the  system  engineering 
process:  the  functional  analysis-synthesis  tasks.  This  type  and  form  of 
guidance  is  inappropriate  for  the  requirements  engineering  activities  which 
mu.,t  be  accomplished  during  the  early  phases  of  the  acquisition  process.  A 
requirements  engineering  definition  must  be  stated  and  the  procedural 
issues  addressed.  The  following  definition  has  been  prepared  during  the 
course  of  the  RSS: 


Requirements  Engineering  is  an  iterative  process  of  defining  the  system  1 
requirements  and  analyzing  the  integrity  of  the  requirements.  This 
process  involves  all  areas  of  system  development  preceding  the  actual 
design  of  the  system.  The  products  of  the  requirements  engineering 
process  can  be  evaluated  for  completeness,  consistency,  testability, 
and  traceability.  The  essential  goal  of  Requirements  Engineering  is 
to  thoroughly  evaluate  the  needs  which  the  system  must  satisfy. 


A  system  in  the  context  of  this  presentation  is  an  aggregate  of 
equipment,  personnel  resources,  capabilities  and  techniques  which 
collectively  perform  an  operational  role.  The  composite  system  includes 
all  related  facilities,  items,  materials,  services,  and  personnel 
required  for  the  system’s  self-sufficient  operational  deployment. 
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This  definition  distinguishes  requirements  engineering  from  other 
engineering  management  tasks  such  as  program  planning,  costing,  trade-off 
studies  and  a  host  of  other  issues  surrounding  the  early  phase  of  systems 
devel opment.  The  definition  distinguishes  requirements  engineering  as 
being  concentrated  upon  the  actual  definition  of  the  system  requirements. 

The  lack  of  specific  approaches  and  techniques  for  militay  requirements 

/ 

engineering  allows  even  the  best  intentioned  analyst  to  digress  rapidly 
from  the  "need"  category  to  the  "how-to"  or  solution  oriented  requirements 
definitions.  This  is  a  natural  tendency  especially  for  any  design-oriented 
engineer,  such  as  a  software  engineer.  During  the  course  of  requirements 
engineering,  the  analyst  must  also  be  aware  that  non-design-oriented  system 
documentation,  such  as  functional  (Type  A,  MIL-STD-490/483  (USAF)  System/ 

Segment  Specifications)  and  development  (Type  B,  MIL-STD-490/483  (USAF)) 
specifications,  is  the  medium  for  communicating  the  system  requirements  to 
the  design  engineers.  The  requirements  engineering  goal  is  to  identify 
"discrete"  requirements  of  the  system  and  to  organize  these  requirements 
in  effective  ways  for  further  analysis.  The  results  of  this  process  is  a 
set  of  "quality  requirements." 

Quality  Requirements  Characteristics 

A  set  of  quality  requirements  consists  of  discrete  requirements,  well 
organized  to  permit  further  analysis  Early  requirements  documents  usually 
have  one  prevailing  characteristic:  the  requirements  are  spread  over 
various  source  documents  and/or  presented  in  various  parts  of  the 
documents,  and  the  requirements  overlap  each  other.  This  is  partly  because 
of  the  fragmented  nature  of  the  early  planning  and  study  efforts  which  are 
formulative  and  investigatory.  The  specification  documents  in  many 
instances  are  products  written  to  meet  acquisition  needs  and  schedules 
rather  than  repositories  of  quality  system  requirements. 

Figure  2  illustrates  the  first  characteristic  of  quality  requirements: 
discreteness.  The  key  to  identifying  discrete  requirements  is  to  break  the 
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source  documentation  into  individual  parts  which  represent  non-overlapping 
requirements.  Requirements  should  then  be  categorized  as  functions  the 
system  must  accomplish  or  as  system  constraints  (performance,  physical, 
operability,  test,  design).1  At  this  point  missing  or  incomplete 
requirements  can  be  more  readily  identified.  This  itemization  and 
categorization  of  requirements  introduces  clarity,  where  as  the  source 
documentation  may  be  overstated,  ambiguous,  redundant,  incomplete,  and 
inconsistent.  Th’S  process  of  itemization  also  provides  the  basis  for 
verifying  the  quality  of  the  requirements  and  for  accessing  the  ability  to 
test  the  requirements  in  the  target  system. 

The  second  characteri stic  of  a  good  statement  of  requirements  is  the 
arrangement  of  the  requirements  in  effective  ways  for  additional  analysis 
and  for  communicating  these  requirements  to  the  using  agency  and  to  design 
engineers.  The  identification  of  discrete  requirements  provides  sane 
awareness  of  omissions  and  gaps  in  the  requirements.  This  awareness  is 
further  heightened  by  organizing  the  requirements  in  ways  which  identify 
all  the  relationships  among  the  discrete  requirements  (Figure  2).  These 
relationships  are  of  three  types:  logical  organizational  relationships, 
system  flow  relationships,  and  requirements  traceability  relationships. 

Loyical  organizational  relationships  are  shown  by  structuring  the  discrete 
functions  and  the  information  requirements  (external  and  internal  input/ 
output)  of  the  system  into  hierarchical  structures.  The  concept  of  a 
functional  hierarchical  structure  was  introduced  into  military  systems 
development,  through  initial  systems  engineering  practices  dating  back  to 
the  1940s.  This  concept,  has  been  maintained  in  military  systems 
development,  and  documentation  throughout,  the  19b0s  and  is  an  integral  part 


The  system  requirement,  types  (functions  and  constraints)  are  discussed 
in  more  detail  in  the  next  few  pages. 
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of  the  current  military  standards  for  system  documentation,  i.e., 
MIL-STD-490  [3],  MIL-STD-483  (USAF)  [4],  OoD  7935. 1-S  [11].  Current 
techniques  for  system  development,  such  as  the  Hierarchical  Input-Output- 
Process  (HIPO  [12])  visual  table  of  contents  and  automated  requirements 
analysis  tools  (PSL/PSA,  CADSAT)  retain  the  principles  of  functional 
hierarchical  structures.  This  form  of  organization  provides  a  view  of  the 
system  as  an  aggregate  of  functions  broken  into  a  logical  arrangement  of 
subordinate  discrete  activities  which  must  be  performed.  A  sample  portion 
from  the  Logicon-Extended  CADSAT  Structure  Report  (Figure  3)  demonstrates 
the  functional  break  out  of  a  space  system*.  This  section  of  the  report 
shows  the  hierarchical  breakdown  of  the  space-system-x  into  discrete 
functions.  Each  breakdown  of  the  functions  is  denoted  by  the  indented 
format  and  the  hierarchy  level  number.  For  example,  boost  breaks  down  into 
four  level  4  subfunctions.  Over  the  course  of  requirements  engineering, 
many  missing  or  incomplete  functions  can  be  directly  identified  from  the 
functional  hierarchical  structure. 

The  discrete  system  inputs,  outputs  (external  I/O)  and  the  internal 
information  requirements  necessary  for  the  system's  operation  can  be 
logically  structured  in  the  same  manner  as  the  functional  hierarchy.  The 
emphasis  again  is  the  arrangement  of  the  information  requirements  into 
structures  by  breaking  the  information  into  logical  subordinate  parts  or 
simply  as  groupings.  A  wel 1 -organi zed  structure  is  effective  in 
communicating  the  information  requirements  and  for  identifying  incomplete 
or  missing  information  requirements. 

System  flow  relationships  can  be  shown  by  organizing  the  discrete 
requirements  in  terms  of  control  flow  and  information  flow.  As  the 
functions  of  the  system  are  defined,  the  control  relationships  between 
them  are  identified.  These  control  relationships  describe  the  logical 
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Figures  3,  4,  and  5  are  CADSAT-like  reports  based  upon  the 
space-system-x  example  contained  in  AFSCM  375-5,  attachment  2,  pp 
128-130  [1] 
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order  in  which  the  system  activities  should  be  accomplished  to  satisfy  the 
system  mission  and  operational  requirements.  Figure  4  is  a  control-flow 
report  for  a  portion  of  the  space- system- x.  In  this  report  (CADSAT  Process 
Chain)  the  flow  of  control  is  from  left  to  right.  Any  number  of  CADSAT 
process  chain  repot  is  can  be  generated  to  provide  the  analyst  with  a 
comprehensive  understanding  of  the  system  control  flow.  Control-flow 
analysis  provides  a  means  of  viewing  the  system  from  an  activity-oriented 
perspective  and  is  often  referred  to  as  functional -fl ow  analysis.  On  the 
other  hand,  1 nformat ion-f 1 ow  analysis  builds  upon  the  information  hierarchy 
structure  by  providing  a  means  of  viewing  the  system  as  an  information 
processing  system.  During  this  analysis  the  flow  relationships  between 
external  system  inputs  and  resulting  outputs  are  identified.  Quite  often 
the  most  effective  means  of  performing  information-f 1 ow  analysis  is  to 
trace  an  output  back  to  system  inputs:  external  data,  messages,  or  stimuli. 
As  a  result  of  this  analysis  the  relationships  between  the  associated 
functions  and  the  internal  information  necessary  to  support  the  derivation 
of  the  output  are  identified.  Control-flow  and  information-f  1  ow  analysis 
will  identify  necessary  changes  and  additions  to  previously  defined 
functions  and  constraints  as  well  as  to  the  hiearchy  structures  and  other 
relationships.  Missing  or  incomplete  requirements  can  be  determined  and 
the  deficiencies  corrected. 


Requirements  traceability  analysis  provides  the  analyst  with  a  means  of 
verifying  the  requirements  by  linking  each  requirement  to  all  forms  of 
source  documentation.  The  Requirements  Traceability  Report  (Figure  5) 
shows  the  traceability  between  specifications  contained  in  separate 
requirements  data  bases.  Figure  5  traces  the  requirements  one 
specification  of  the  space- system- x  to  the  allocated  requirements  contained 
in  the  next  level  of  specification.  This  form  of  analysis  aids  in 
validating  the  requirements.  Relationships  can  also  be  defined  to  other 
pertinent  studies,  analyses,  and  plans  which  are  being  accomplished 
concurrently  with  the  requirements  engineering  activities.  The  links  to 
associated  system  plans,  analyses,  and  studies  accomplished  prior  to, 
during,  and  subsequent  to  the  start  of  formal  requirements  engineering  are 


Figure  4.  Space  System  X:  Control-Flow  Diagram 


Figure  5.  Space  System  X:  Requirements  Traceability  Report 
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crucial  to  the  overall  systems  engineering  concept.  Throughout  the 
requirements  engineering  activities  the  analyst  must  be  able  to  evaluate 
the  impact  of  changes  to  the  requirements.  Once  the  area  of  impact  is 
identified  in  the  requirements  engineering  products  (Functional  and  1/0 
hierarchies,  control  and  i  nf ormat i on- f 1 ows  etc.)  the  traceability 
relationships  provide  the  capability  to  readily  identify  associated  impacts 
to  the  system  and  to  trace  the  impacts  to  all  other  associated 
documentat ion.  The  impact  can  be  readily  analyzed  and  the  appropriate 
actions  taken. 

Discrete  and  wel 1 -organi zed  requirements  support  the  primary  goal  of 
defining  the  operational  mission  needs  of  the  using  activity  while  giving 
the  analyst  visibility  and  control  over  the  system  definition  process. 
Discrete  and  well-organized  requirements  are  prerequisites  for  the  creation 
of  system  functional  or  development  specifications. 

System  Requirement  Types 

Understanding  the  various  system  requirements  types  and  their  use 
contributes  signif icantly  to  the  identification  of  discrete  requirements 
and,  therefore,  quality  requirements  definitions.  Table  1  shows  that  there 
are  two  sets  into  which  system  requirements  may  be  organized. 

The  functional  requirements  set  is  the  backbone  of  the  system  requirements 
engineering  process.  It  is  within  this  set  of  requirements  that  the  pure 
design-free  or  solution  independent  needs  are  declared.  Simply  stated, 
and  the  functional  requi rements  represent  the  total  discrete  system 
activities  required  to  achieve  a  specific  objective.  A  functional 
requirement  identifies  what  must  be  accomplished  without  identifying  aqy 
aspect  concerning  the  means  such  as  hardware,  computer  programs,  personnel, 
facilities,  or  procedural  data.  The  functional  requirements  represent  a 
problem  statement  devoid  of  any  overtone  or  specifics  regarding  real  or 
conceptual  solutions  which  satisfy  any  or  part  of  the  needed  functions. 
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Table  1.  System  Requirement  Types 


SYSTEM 

REQUIREMENTS 


FUNCTIONAL 

REQUIREMENTS 

(functions) 

The  set  of  discrete  functions  which 
identify  the  pure  design  free  or 
solution  independent  needs  of  the  system 
as  a  whole.  The  functional  requirements 
identify  what  must  be  accomplished  while 
avoiding  solution  statements  or  overtones. 

PERFORMANCE 

How  well  the  system 
functions  must  be 
accompl i shed, such  as 
timeliness  and  accuracy. 
Also  called  performance 
characteristics, 
MIL-STD-490. 

PHYSICAL 

Influences  the  design 
solution  in  a  physical 
manner:  power,  size, 
weight,  environment, 
human  factors,  existing 
system  interfaces,  GFP, 
etc.  Also  called 
Physical  Characteris¬ 
tics,  MIL-STD-490. 

CONSTRAINT 

REQUIREMENTS 

OPERABILITY 

Reliability,  maintain¬ 
ability,  availability, 
dependability. 

(Constraints) 

TEST 

Identify  the  functional, 
performance,  physical, 
operability,  and 
design  requirements 
which  will  be  evaluated 
during  system  integra¬ 
tion  and  test. 

DESIGN 

The  minimum  or  essen¬ 
tial  design  and 
construction  require¬ 
ments  which  are  a 
constraint  on  the 
functional  require¬ 
ments  of  the  system 
during  the  design  and 
construction  of  the 
system  end-items 
(CIs/  CPCIs).  Also 
cal  led  Design  and 
Construction,  MIL-STD- 
490. 
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Some  examples  of  discrete  top-level  functions  for  an  electronic  system 
might  be  surveillance,  tracking,  identification,  interceptor  control,  and 
communications. 


The  second  set  of  requirements  is  the  constraint  set  which  consists  of  five 
requi rements  types:  performance,  physical,  operability  ,  test,  and  design 
(as  described  in  Table  1).  The  constraint  set  modifies  the  functional 
requirements  set.  Without  the  constraint  set,  a  solution  for  the  system 
functional  requirements  could  not  be  achieved.  However .excessi ve  or 
unrealistic  constraints  can  eliminate  all  solutions  or  increase  the 
technical  risks  and  cost  of  the  solution.  Therefore,  the  identification  and 
management  of  the  constraint  requirement  set  must  be  achieved  with  care. 
Whenever  specific  constraints  are  identified,  there  must  be  sufficient 
justification,  such  as  an  engineering  analysis,  which  clearly  shows  that 
the  constraint  is  a  reasonable,  necessary,  and  practicable,  and  represents 
an  actual  requirement  and  not  just  a  desirable  feature. 


Requirements  Engineering  Procedure 


Requirements  engineering  is  an  iterati ve  process  of  defining  the  system 
requirements  and  analyzing  the  integrity  of  the  requirements  for 
completeness,  consistency,  testability,  and  traceability.  As  the  process 
continues,  the  system  requirements  are  defined  and  analyzed  in  a 
progressively  expanding  manner.  The  definition  and  analysis  activities 
will  move  from  one  area  of  concentration  to  another  as  the  results  of 
previous  activities  reveal  areas  needing  additional  work.  No  singular 
approach  can  be  rigidly  defined  and  applied  which  can  take  into  account  the 
many  possibilities  which  must  be  considered.  However,  guidelines  for 
requirements  engineering  and  associated  tasks  can  be  defined  and  then 
tailored  for  specific  requirements  engineering  appl ications.  The  following 
is  a  synopsis  of  the  requirements  engineering  procedures  contained  in 
Volume  III,  Requirements  Engineering  Guidebook.  The  general  framework  for 
requirements  engineering  is  illustrated  in  Figure  6.  Each  block  represents 
a  unique  requirements  engineering  activity  which  must  be  accomplished  in 
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Figure  6.  Requirements  Engineering  Procedures 


defining  jnd  analysing  system  requirements.  There  is  constant  interaction 
between  the  activities  ot  each  block,  and  although  each  block  appears  as  a 
single  activity,  it  is  in  tact  part  of  a  continuum.  Selection  of  an  actual 
approach  for  a  given  application  is  one  ot  the  tasks  (BLOCK  2). 

The  activities  identified  in  Figure  b  may  be  organized  into  five  general 
steps.  In  step  1  (BLOCKS  1-3)  pertinent  source  documentation  is  identified 
and  reviewed.  The  analysis  team  develops  a  requirements  engineering  plan 
which  identifies  the  resources  required  and  the  specific  approach  to  be 
taken  in  performing  the  remaining  requirements  engineering  tasks  (BLOCKS 
3-14).  Step  2  involves  identifying  and  organizing  the  activity  structure 
and  information  structure(s)  of  the  system.  The  requirements  engineering 
tasks  associated  with  BLOCKS  3-S  are  concentrated  on  analyzing  the  system 
source  documentation  to  identity  activities  performed  by  the  system.  If 
the  system  is  primarily  activity  oriented,  such  as  a  command  and  control 
system,  the  analysis  activities  may  be  concentrated  on  the  tasks  identified 
in  BLOCKS  3-b.  It  on  the  other  hand,  the  system  is  primarily  information 
oriented,  as  in  the  case  ot  a  communications  system  or  an  automated  data 
processing  system  (ADP)  application  such  as  a  management  information 
system,  the  analysis  activities  may  be  concentrated  on  the  tasks  associated 
with  BLOCKS  6-8.  Generally  the  analysis  team  performs  the  activities 
associated  with  BLOCKS  3-b  and  BLOCKS  b-8  concurrently.  During  step  3  the 
flow  of  control  between  system  functions  (BLOCK  9)  and  the  flow  of 
information  into,  within,  and  out  of  the  system  (BLOCK  10  )  can  be  defined 
and  analyzed.  Step  4  involves  analyzing  the  system  requirements  for 
testability  (BLOCK  11)  and  preparing  required  specification  documents 
(BLOCK  l.’).  Step  S  consists  of  two  activities  which  are  continuously 
performed  in  conjunction  with  the  activities  of  BLOCKS  3-13.  Source 
documentation  references  are  maintained  for  each  requirement  identified  and 
traceability  analysis  is  performed  (BLOCK  13).  Various  consistency  and 
completeness  checks  (BLOCK  14)  are  also  accomplished.  Volume  111  contains 
a  more  detailed  description  of  the  activitii  to  be  performed  and 
standards  to  be  applied,  including  a  description  of  Conceptual  and 
Validation  Phase  issues. 
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REQUIREMENTS  ENGINEERING  TOOL  CAPABILITIES 


The  following  paragraphs  describe  the  role  of  automation  in  requirements 
engineering  and  summarizes  a  more  detailed  discussion  of  automated  tool 
capabilities  presented  in  Volume  II. 

Intrinsic  Capabilities  of  Automated  Tool s 

Automated  tools  like  CADSAT  assist  requirements  engineering  in  four  ways: 

•  Provide  a  medium  for  formal  requirements  definition 

\ 

•  PerfomTxudimentary  analysis 

•  Produce  documentation 

•  Permit  a  flexible,  iterative  approach  to  requirements 
definition 

Automated  tools, like  CADSAT,  consist  of  two  parts:  a  language  and  an 
analyzer.  The  language  provides  the  means  for  describing  the  requirements 
for  functional  and  development  specifications.1  The  report,  language  and 
analyzer  can  be  used  to  assist  the  analyst  in  completing  the  t,  ;!>s 
described  in  the  Requirements  Engineering  Guidebook  (Volume  III). 


In  Air  Force  system  acquisitions  the  functional  specification  is  the 
system/ segment  specification  (Type  A.  M1L-STD-483  (USAF),  Appendix  111) 
and  the  development  specifications  are  Type  B  specifications.  The 
Computer  Program  Configuration  Item  Specification  (Type  B5,  M1L-STD-483 
(USAF),  Appendix  VI)  is  the  primary  development  specification  addressed 
in  this  study. 
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Language  Objects  and  Relationships 

The  language  objects  and  relationships  described  in  this  paragraph 
incorporate  all  the  system  requirements  and  provide  the  means  to  analyze 
the  requirements  through  automated  means.  The  "nouns"  of  a  requirements 
definition  language  are  called  objects.  For  example,  there  are  objects 
for  describing  system  functions  and  other  objects  for  describing  system 
external  and  internal  inputs  and  outputs.  Each  object  is  named.  For 
example,  the  requirement,  "sense  stage  preparation  signal  from  automatic 
systems,"  is  a  functional  requirement  and  might  by  entered  in  the 
requirements  data  base  as  a  function  object  called: 

sense- stage- separation- signal -from- auto- systems. 

Depending  on  the  application  of  the  automated  tool,  not  every  aspect  of 
the  requirements  has  to  be  formalized.  The  essential  objective  is  to 
make  the  requirements  discrete  and  to  organize  the  requirements  as  a 
basis  for  further  analysis. 

The  language  should  allow  various  relationships  between  objects  to  be 
described.  These  are  the  "verbs"  of  the  language.  Several  relationships 
describe  simple  requi rement-to-requi rement  and  requi rement-to- document 
associations.  For  example,  certain  relationships  establish  the 
hierarchical  structure  of  functional  requirements  (Figures  3  and  7)  while 
others  define  the  hierarchical  structure  of  system  external  and  internal 
inputs  and  outputs  (Figure  8). 

Some  relationships  describe  the  flow  of  control  among  functions  (Figure 
9).  Some  of  these  control  flow  relationships  are  also  illustrated  in 
Figure  3.  Other  relationships  describe  the  flow  of  information  into, 
within,  and  out  of  the  system  (Figure  10).  Each  requirement  object 
(function,  constraint,  I/O,  etc.)  and  relationship  (functional  and 
information  (I/O)  hierarchy,  control  and  information  flow,  etc.)  can  be 
supplemented  by  a  textual  description. 
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Figure  7.  Functional  Hierarchical  Structure 
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Figure  8.  I/O  Hierarchical  Structu 
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The  Analyzer 


The  analyzer  is  the  second  part  of  an  automated  tool  like  CADSAT.  It 
generates  a  series  of  reports.  The  reports,  essential  for  the  application 
of  the  Requriements  Engineering  Guidebook,  can  be  grouped  into  six  general 
report  categories:  requirements  data  base  management,  functional  analysis, 
I/O  analysis,  traceability  analysis,  test  analysis  and  documentation. 

Requirements  Data  Base  Management 


Change  Requirements  Data  Base  Reports  -  The  analyzer  handles  requirements 
definition  entries  into  the  requirements  data  base  and  changes  definitions 
al ready  in  the  data  base.  The  report  is  in  the  form  of  a  listing  of 
changes  made  to  the  requirements  data  base. 

Object  Information  Report  -  The  object  information  report  is  used  to 
cneck  the  contents  of  the  requirements  data  base.  Provided  with  a  list 
of  object  names,  the  report  supplies  a  listing  of  selected  information 
about  each  object. 


Source  Document  Summary  Report  -  The  Source  Document.  Suninary  report  is 
used  to  compare  the  requirements  data  base  contents  against  the  source 
documentation.  The  report  presents  a  sequential  list  of  all  source 
document  references. 

Identify  Specified  Objects  Report  -  The  purpose  of  this  report,  is  to 
retrieve  requested  object,  and  relationship  information  from  the 
requirements  data  base.  It  relieves  the  analyst  of  simple  but.  time 
consuming  tasks.  For  example,  this  report  aids  in  finding  sources  which 
have  not  been  completely  analyzed  and  referenced  or  functions  which  have  no 
control  or  information  flow  relationships. 

Requirements  Data  Base  Status  Reports  -  The  Requirements  Data  Base  Status 
Reports  provide  summary  information  on  the  contents  of  the  requirements 
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data  base.  Requirements  data  base  objects  are  listed  along  with  various 
statistics  showing  the  quantities,  percentages  (as  appropri ate ) ,  and 
quality  of  each  object  in  the  requirements  data  base. 

Functional  Analysis 

Functional  Hierarchical  Structure  Report  -  The  primary  purpose  of  this 
report  is  to  provide  requirements  visibility.  The  report  uses  the 
functional  hierarchical  structure  information  contained  in  the  requirements 
data  base  to  present  the  breakdown  of  system  functions  from  the  general  to 
the  specific.  The  secondary  purpose  of  the  Functional  Hierarchical  Struc¬ 
ture  report  is  to  present  requirements  data  base  information  in  a  format 
that  is  easily  used  by  the  analyst. 

Control-Flow  Report  -  The  Control-Flow  report  helps  identify  the 
completeness  and  consistency  of  system  control  flow.  On  input  of  a 
function  name,  the  report  traces  the  control  flow  forward  or  backward  by  a 
specified  number  of  functions.  Missing  control  flow  logic  is  highlighted 
by  a  premature  termination  of  the  flow  sequence  in  the  report. 

I/O  Function  Interaction  Report  -  The  I/O  Function  Interaction  report 
shows  the  information  flow  for  selected  functions  or  I/O.  The  report  is 
useful  when  the  analyst  is  roncerned  with  a  portion  of  the  system  relative 
to  a  selected  group  of  i/0.  It  answers  such  questions  as  "How  does  the 
system  I/O  tie  these  functions  together?"  or  "Where  does  thi^  I/O  fit  into 
the  system?"  \ 

I/O  Analysis  ■ 

i 

I/O  Hierarchical  Structure  Report  -  This  report  prints  selected  parts  of 
the  I/O  structure.  The  report  is  used  by  the  analyst  to  review  and  upgrade 
the  1/0  structure.  The  final  results  provide  visibility  into;  the  system 
I/O  structure. 


Information-Flow  Report  -  Information-Flow  reports  help  to  assure  a 
complete  and  consistent  I/O  description  of  the  system.  The  report  can  also 
be  prompted  to  trace  system  I/O  from  the  system  external  inputs  toward  the 
external  outputs  (or  vice  versa).  The  report  helps  the  analyst  to  examine 
the  information  flow  for  logical  errors  and  inconsistencies.  When  the 
report  is  unable  to  trace  back  to  system  external  inputs,  missing  functions 
or  flow  relationships  are  indicated. 


Traceability  Analysis 

Find  Related  Requirements  Report  -  This  report  aids  change  impact  analysis 
by  using  the  requirements  data  base  information  to  locate  requirements 
which  are  in  some  way  related  to  a  requirement  which  may  be  changed. 

Requirements  Traceability  Report  -  The  Requirements  Traceability  report 
shows  the  traceability  of  requirements  from  one  set  of  documentation  to 
another.  Various  options  are  provided.  Requirements  are  traced  from  the 
source  documentation  to  the  requirements  data  base  (based  on  a  second  set 
of  source  documentation)  or  from  the  source  documentation  to  the  second 
requirements  data  base. 

Test  Analysis 

Test  Reports  -  The  test  reports  are  used  to  evaluate  the  quality  and 
completeness  of  test  plans  and  procedures.  Reports  can  be  prepared  for 
each  test  case  defined  for  the  information  and  control  flows.  The  test 
reports  show  the  relationship  between  system  flow  test  points  and 
associated  test  cases,  test  plans  and  procedures  and  other  pertinent 
source  documentation. 

Documentation 


Requirement  Document  Reports  -  The  Requirement  Document  Reports  are 


automated  reports  which  can  be  used  directly  in  system  documentation. 
These  reports  should  conform  to  the  format  requirements  of  the  prescribed 
documentation  standard,  such  as  MIL-STD-490/483  (USAF). 

6.  ADDITIONAL  STUDY  RESULTS 

The  primary  results  of  the  Requirements  Standards  Study  are  the 
Requirements  Engineering  Guidebook  and  the  description  of  automated  tool 
capabilities.  Additional  results  include:  an  example  illustrating 
application  of  the  Guidebook  in  an  Air  Force  system  acquisition,  a 
description  of  an  implementation  approach  for  applying  the  Guidebook  in  Air 
Force  acquisitions,  and  a  discussion  of  two  approaches  for  employing  CADSAT 
in  the  requirements  engineering  activities  presented  in  the  Guidebook. 
These  additional  results  are  summarized  below. 

Requirements  Engineering  Example 

The  requirements  engineering  example  presented  in  Volume  II,  Appendix  E 
was  derived  from  actual  requirements  engineering  activities  associated 
with  an  Air  Force  surveillance  system  acquisition.  Excerpts  from  the 
surveillance  system  segment  specification  (Type  A)  are  included  at  the 
conclusion  of  the  example.  The  example  presents  a  description  of  the 
actual  requirements  engineering  performed  on  the  specification  in 
conjunction  with  the  use  of  an  automated  requirements  tool,  Logicon- 
Extended  CADSAT.  Cross  references  between  the  example  description  and  the 
requirements  engineering  activities  in  the  Requirements  Engineering 
Guidebook  are  identifed  by  references  to  appropriate  activities. 

Implementation  Approach 

The  implementation  of  the  Requirements  Engineering  Guidebook  must  address 
certain  issues,  practices,  and  policies  within  the  Air  Force  systems 
acquisition  life  cycle.  The  present  lack  of  direction  provides  little 
visibility  into  the  requirements  engineering  activities  of  Air  Force 
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program  office  engineering  staffs  or  their  support  engineers.  The 
principle  program  office  goal  is  typically  to  produce  a  draft 
system/ segment  specification  which  satisfies  program  office  schedule  and 
milestone  objectives.  The  current  specification  preparation  process  is 
generally  an  iterative  drafting-review-redrafting  process  which  takes  place 
over  many  months.  As  a  result,  discrete  and  well  orgainzed  requirements 
are  not  apparent  and  are  seldom  easy  to  identify  in  the  resulting 
specification  documents.  The  Requirements  Engineering  Guidebook,  like  the 
concept  of  AFSCM  375-5,  places  the  emphasis  on  engineering  tasks  preceding 
the  preparation  of  specifications.  The  various  forms  of  intermediate 
documentation  required  are  more  suitable  to  the  needs  of  identifying 
recording,  and  communicating  the  requirements  as  they  evolve. 
Implementation  of  the  Guidebook  must,  on  the  one  hand,  recognize  that 
intermediate  documentation  provides  the  necessary  visibility  leading  to 
the  preparation  of  good  system  requirements  documents  (Type  A  and  B5 
specifications)  while  also  recognizing  that  automated  assistance  is 
necessary  to  reduce  the  burden  in  production  and  maintenance  of  required 
intermediate  and  final  system  documentation. 

The  introduction  of  the  Guidebook  in  the  Air  Force  program  office 
environment  for  use  in  preparing  or  managing  the  preparation  of 
specifications  will  necessitate  training  in  order  to  be  successful. 
Although  a  requirement  to  apply  the  Guidebook  could  be  directed  towards 
program  offices,  the  lack  of  training  coupled  with  a  certain  resistance 
factor  could  result  in  the  Guidebook  being  utilized  only  minimally,  thereby 
lessening  the  benefits  which  the  Guidebook  can  provide.  The  training  must 
encourage  a  positive  attitude  and  assist  engineers  in  performing  their 
work. 

Application  of  the  Guidebook  will  require  changes  in  current  regulations, 
standards,  and  specifications.  However,  these  changes  are  minor.  They 
are  essentially  refinements  and  clarifications.  The  concept  of 
specification  development  (Type  A,  Type  B,  etc.)  is  a  well  established 
procedure  for  successive  refinement  of  "needs"  which  leads  to  a  "design 
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to"  concept  and  ultimately  to  the  realities  of  an  "as  built"  product. 
The  Requirements  Engineering  Guidebook,  ’s  supportive  of  this  system 
acquisition  concept.  However,  the  required  formats  for  specification 
preparation  within  these  current  standards  could  be  improved,  especially 
with  consideration  to  automated  documentation  and  specificat  n  generation 
from  computer  maintained  requirements  data  base. 

Various  Air  Force  quality  assurance  requirements  and  guidelines  would 
also  require  changes.  The  Requirements  Engineering  Guidebook  intermediate 
documentation  requirements  provide  quality  assurance  personnel  with  the 
ability  to  evaluate  the  progress  of  systems  requirements  definition  and 
analysis,  and  to  ensure  that  the  requirements  are  clearly  stated  and 
unambiguous.  Changes  to  current  quality  assurance  tasking  should  require  a 
more  active  role  in  the  requirements  engineering  activities  and  review  of 
intermediate  documentation. 

Changes  are  also  necessary  to  the  engineering  management  concepts  required 
in  MIL -STD -499A  (USAF)  and  AFR  800-3.  MIL-STD-499A  describes  the 
fundamental  concepts  and  criteria  against  which  contractors  can  propose 
their  individual  internal  procedures  as  a  means  of  satisfying  Air  Force 
engineering  requirements.  It  does  not  specifically  address  requirements 
engineering.  The  definition  of  requirements  engineering  should  be 
incorporated  into  MIL-ST0-499A.  Other  changes  should  direct  the  contractor 
to  address  requirements  engineering  in  the  System  Engineering  Management 
Plan  (SEMP).  Finally,  the  system  program  office  acquisition  management 
guidance  (AFR  800-3,  '  'irineering  for  Defense  Systems)  should  be  modified  in 
conjunction  w’th  l  0-499A.  Again  the  definition  of  requirements 
engineering  should  be  incorporated  into  AFR  800-3,  and  specific  direction 
for  the  program  office  to  perform  requirements  engineering  should  also  be 
included  as  a  separate  acquisition  management  task. 

Automated  T ool  Design  Approaches 


The  requirements  engineering  tool  capabilities  described  in  Section  5 
represents  the  minimum  capabilities  necessary  to  support  the  Requirements 


Engineering  Guidebook.  Each  tool  capability  has  been  evaluated  against 
the  basic  CADSAT  capabilities  as  well  as  the  Logicon-Extended  CADSAT. 
Basic  CADSAT  satisfies  most  of  the  standard  requirements  engineering 
needs,  especially  the  language  capabi 1 ities.  General  deficiencies  are  in 
the  report  generation  area.  These  deficiencies  are  both  human  engineering 
and  system  engineering  problems. 

The  Logicon-Extended  CADSAT  was  developed  in  conjunction  with  the 
surveillance  system  requirements  engineering  activities.  Since  this  work 
concentrated  upon  early  requirements  engineering  (Type  A  and  Type  BS 
specifications),  the  enhancements  to  the  basic  CADSAT  satisfy  a  number  of 
essential  early  requirements  engineering  needs.  The  extensions  concentrate 
on  the  analyst  needs  for  improved  report  generation.  Liberties  with  the 
language  were  taken,  the  language  features  were  employed  differently  in 
some  cases  than  originally  intended.  The  basic  and  the  extended  CADSAT 
satisfy  most  of  the  needs  of  the  capabilities  list  and  therefore  the 
Guidebook.  One  approach  would  be  to  employ  the  basic  CADSAT  with  certain 
extended  CADSAT  features,  primarily  to  increase  ease  of  use  and  provide 
additional  reports.  The  second  approach  would  be  to  add  additional 
capabilities  (reports)  as  well  as  to  achieve  the  objectives  of  the  first 
approach.  These  improvements  would  build  upon  the  present  design  of  CADSA1 
including  its  extensions. 

7.  RESULTS  AND  RECOMMLNDATIONS 

The  Requirements  Lngineering  Guidebook 


The  Requirements  Engineering  Guidebook  has  been  developed  from  analysis 
of  past  and  present  DoD  and  Air  Force  system  engineering  practices.  It. 
incorporates  established  requirements  engineering  techniques  and  approaches 
of  many  leading  defense  contractors.  The  Requirements  Engineering 
Guidebook  provides  the  necessary  guidance  for  requirements  engineering 
which  is  not  described  in  current  Air  Force  regulations,  standards,  or 
specifications.  The  Guidebook  provides  a  general  roadmap  for  performing 


system  requirements  definition  and  analysis.  It  begins  with  a  definition 
of  the  inTt-i^^user  requirements  and  continues  through  the  complete 
definition  and  anaTys-i-s^of  the  system  prior  to  its  development.  The 
Guidebook  allows  for  a  flexible^appmach  in  its  application  while  providing 
the  necessary  guidance  for  government  and  contractor  system  analysts  to 
plan  and  perform  requirements  engineering  activities.  It  is  recommended 
that  the  Guidebook  be  applied  to  selected  programs  to  allow  for 
cl ari f i cat i on  and  improvement  of  its  contents  and  presentation.  The 
application  of  the  Guidebook  as  a  general  guide  may  lead  to  a  more 
formalized  approach  such  as  direct  contract  applications  or  a  formal 
military  standard.  The  relationship  of  the  Requirements  Engineering 
Guidebook  to  later  phases  of  the  Air  Force  system  life  cycle  (such  as  in 
the  full-scale  development  phase)  should  be  studied  and  presented  as  an 
extension  to  the  Requirements  Standards  Study. 

CADSAT  Enhancements 


CADSAT  has  been  found  to  be  an  effective  tool  for  accomplishing  the 
requirements  engineering  activities  described  in  the  Requirements 
Engineering  Guidebook.  Certain  modifications,  additions,  and  improvements 
to  CADSAT  have  been  identified  during  this  study.  These  enhancements  are 
oriented  to  improving  the  human  engineering  and  system  engineering  process. 
The  recommended  improvements  include  simplifying  the  language,  streamlining 
the  analyzer  to  eliminate  unnecessary  reports,  improving  existing  report 
capabilities,  and  increasing  the  overall  performance  and  design  of  CADSAT. 
These  enhancements  would  increase  the  effectiveness  of  CADSAT  in  support  of 
the  application  of  the  Requirements  Engineering  Guidebook  and  would  improve 
CADSAT's  efficiency.  Extensive  use  of  CADSAT  in  the  Air  Force  acquisition 
environment  will  require  continuing  enhancements  to  satisfy  additional 
needs  as  described  below. 

Extended  CADSAT  Capabilities 

Four  promising  uses  of  a  requirements  engineering  tool  like  the  Logicon- 
Ext.ended  CADSAT  are  (1)  automated  specification  generation  from  the 
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requirements  data  base,  (2)  management  information  system  appl ications, 
(3)  additional  query- report i ng  capabilities,  and  (4)  simulation 
capabilities.  The  first  three  can  be  presently  achieved  to  a  limited  degree 
by  using  CADSAT.  Simulation  using  a  requirements  engineering  tool  is 
considered  too  experimental  to  recommend  as  an  essential  capability  for  a 
requirements  engineering  tool  at  this  time.  Improvements  in  automated 
specification  generation  from  a  requirements  data  base  is  considered  the 
most  beneficial  enhancement  to  CADSAT.  extended  query-reporting 
capabilities  and  management  information  system  features  would  be  the  next, 
most  beneficial  extension  beyond  the  essential  capabilities  identified  to 
support  the  Guidebook.  Finally,  simulation  should  continue  to  be 
investigated  and  experimental  approaches  encouraged.  A  thorough  analysis 
of  the  benefits  of  simulation  in  the  Air  Force  acquisition  environment., 
the  identification  of  requirements  engineering  simulation  capabilities,  and 
the  development  of  the  specified  capabilities  into  current,  requirement 
engineering  tools  such  as  CADSAT  is  recommended  as  a  principle  area  of 
research  at.  this  time. 

Evolu  t  i  ouary^)]!  roach 

The  application  of  the  Requirements  engineering  Guidebook  and  the 
recommended  changes  to  existing  practices,  regulations,  standards,  and 
spec  i  f  i  cat.  i  ons  must  proceed  in  a  careful  and  selective  manner.  Ihe 
incompatibility  of  the  Guidebook  with  some  current,  acquisition  practices 
will  demand  changes  to  existing  regulations,  standards,  and  specifications 
over  a  period  of  time  to  allow  the  application  of  the  Guidebook  to  evolve. 
Essential  to  the  promotion  of  the  Guidebook  is  adequate  training  for  the 
engineers  who  must  apply  the  Guidebook  to  their  programs.  The  key  element 
of  this  training  will  be  to  present,  the  Guidebook  as  guidelines  and 
standards  for  improved  requirements  engineering.  The  success  of  the 
documentation  and  analysis  requirements  of  the  Guidebook  will  depend  upon 
the  availability  of  requirements  engineering  tools  like  CADSAT.  The 
intermediate  documentation  and  analysis  needs  which  are  essential  to  the 
requirement,  engineering  process  are  not  considered  to  be  easily 
accomplished  without  automated  assistance.  In  addition,  the  specific 


issues  of  the  acquisition  environment,  the  application  of  the  Guidebook, 
and  the  use  of  automated  tools  must  be  addressed  in  specific  methodologies 
for  each  acquisition  environment  as  described  below. 


Requirements  Engineering  Methodology 

The  Requirements  Engineering  Guidebook  presented  in  this  report  provides 
the  procedural  framework  for  the  definition  and  analysis  of  system 
requirements  for  any  Air  Force  systems  development.  The  associated  list 
of  automated  tool  capabilities  was  developed  to  complement  the  Guidebook 
and  to  facilitate  the  definition,  analysis,  and  documentation  of  the  system 
requirements.  Specific  approaches  for  the  application  of  the  Guidebook 
within  various  acquisition  environments  and  the  integration  of  automated 
tool  capabilities  in  support  of  the  requirements  engineering  tasks 
described  in  the  Guidebook  can  be  facilitated  by  specific  guidance  -  a 
requirements  engineering  methodology.  The  methodology  provides  the  means 
of  adapting  the  procedures  and  tools  to  specific  acquisition  environments 
and  facilitates  the  introduction  of  the  Guidebook  and  automated  tools.  The 
development  of  a  requirements  engineering  methodology  for  the  ESD 
acquisition  environment  based  upon  the  Requirements  Engineering  Guidebook 
and  automated  assistance  from  CADSAT  can  proceed  as  an  extension  to  the 
Requirements  Standards  Study.  Additional  guidelines  for  other  acquisition 
environments  can  proceed  based  on  the  ESD  methodology. 
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MISSION 

of 

Rome  Air  Development  Center 

RAVC  plan*  and  executes  research,  development,  test  and 
selected  acquisition  pA.ogn.am  in  support  of  Command,  Control 
Communication*  and  Intelligence.  (C3 1)  activities.  Technical 
and  engineering  Support  utithin  area*  of  technical  competence 
i*  provided  to  ESV  Program  Office*  (PO-s)  and  other  ESD 
elements.  The  principal  technical  mission  area*  are 
communication* ,  electromagnetic  guidance  and  control,  sur¬ 
veillance  0(5  ground  and  aerospace  objects,  intelligence  data 
collection  and  handling,  information  system  technology, 
ionospheric  propagation,  solid  state  sciences,  microuave 
physics  and  electronic  reliability,  maintainability  and 
compatibility. 


